情形|本文_linux多线程双buffer“无锁”设计

篇首语：本文由编程笔记#小编为大家整理，主要介绍了linux多线程--双buffer“无锁”设计相关的知识，希望对你有一定的参考价值。

在linux多线程环境下对同一变量进行读写时&＃xff0c;经常会遇到读写的原子性问题&＃xff0c;即会出现竞争条件。为了解决多个线程对同一变量访问时的竞争条件问题&＃xff0c;操作系统层面提供了锁、信号量、条件变量等几种线程同步机制。如果对变量的每次访问都使用上述机制&＃xff0c;由于系统调用会陷入内核空间&＃xff0c;需要频繁的进行上下文切换&＃xff0c;这就导致了程序的时间开销比较大。

自然的&＃xff0c;我们就想到&＃xff0c;在多线程环境中&＃xff0c;在某些情况下是否能减少甚至避免使用系统调用&＃xff1f;答案是肯定的。

如果对多线程下的变量访问进行分析&＃xff0c;可以看到&＃xff0c;线程对变量的访问可以分为以下几类&＃xff1a;

• 一个线程写&＃xff0c;另一个线程读&＃xff0c;简称一写一读
• 多个线程写&＃xff0c;一个线程读&＃xff0c;简称多写一读
• 一个线程写&＃xff0c;多个线程读&＃xff0c;简称一写多读。
• 多个线程写&＃xff0c;多个线程读&＃xff0c;简称多写多读。

在linux 系统中&＃xff0c;多个线程同时读一个变量是不需要同步的&＃xff0c;而多个线程同时写一个变量或一个线程写而其他线程读某个变量&＃xff0c;是需要同步的&＃xff0c;可以总结为&＃xff1a;”多读不互斥&＃xff0c;而读写和多写互斥“。

由于多个线程对同一变量的读不需要同步&＃xff0c;因而一写多读和一写一读并无本质区别&＃xff0c;进而可以把多线程下对变量访问依据是否需要同步而合并成如下三类&＃xff1a;

• 一写多读
• 多写一读
• 多写多读

解决上面所有的互斥&＃xff0c;都可以使用系统调用。上面已经提到&＃xff0c;在某些情况下我们是可以避免使用代价高昂的系统调用的。而“一写多读”就是这些特殊情况中的一种。

使用系统调用进行同步的主要问题在于频繁切换上下文耗时较长&＃xff0c;而后台系统的处理速度又是除正确性之外最为关键的指标。为提高系统的运行速度&＃xff0c;我们可以使用用其他系统资源来换取时间的办法&＃xff0c;从而避免使用锁之类系统调用。在这些方法中&＃xff0c;最常见的就是用空间换取时间。

针对一写多读的情况&＃xff0c;可以使用”双 buffer“ 及共享指针机制来实现对同一变量高效访问&＃xff0c;同时又能保证不会出现竞争条件。这一实现的技术关键点在于以下两个方面&＃xff1a;

• 双 buffer 的备份机制&＃xff0c;避免了同时读写同一变量。双buffer 就是指对于通常要被多个线程访问的变量&＃xff0c;再额外定义一个备份变量。由于是一写多读&＃xff0c;写线程只向备份变量中写入&＃xff0c;而所有的读线程只需要访问主变量本身即可。当写进程对备份变量的写操作完成后&＃xff0c;会触发主变量指针和备份变量指针的互换操作&＃xff0c;即指针切换&＃xff0c;从而将原变量和备份变量的身份进行互换&＃xff0c;达到数据更新的目的。
• 共享指针 shared_ptr&＃xff0c;由于其记录了对变量的引用次数&＃xff0c;因而可以避免指针切换时的“访问丢失”问题。

为了便于理解&＃xff0c;本文使用 C&＃43;&＃43; 中的 map 类型变量作为示意&＃xff0c;当然&＃xff0c;本文的方法可以推广到一写多读模式下任意数据类型的更新中。使用双 buffer 的示意图如下&＃xff1a;

注意ptr 和 bak_ptr 都是整个map 的指针&＃xff0c;上面蓝色箭头表示通过两个指针访问 map 中的元素&＃xff0c;ptr 和bak_ptr 本身并不指向元素。

在系统启动时&＃xff0c;把两个智能指针分别初始化为一个主map 和一个备份 map。之后把全部数据更新到主map中开始对外提供服务。当外部需要读取数据时(多读&＃xff09;&＃xff0c;全部通过主map 的智能指针 ptr 来实现。而数据的更新全部通过备份map 的指针bak_ptr 来实现。由此可以看出&＃xff0c;由于使用了两个map&＃xff0c;即双buffer&＃xff0c;使得数据的读和写进行了分离&＃xff0c;互不影响&＃xff0c;不会出现竞争条件&＃xff0c;避免了锁的使用。

相关视频推荐

聊点通俗的&＃xff0c;自旋锁&＃xff0c;互斥锁&＃xff0c;原子操作&＃xff0c;CAS

多进程、多线程、线程使用场景分析

学习地址&＃xff1a;C/C&＃43;&＃43;Linux服务器开发/后台架构师

需要C/C&＃43;&＃43; Linux服务器架构师学习资料加qun812855908获取&＃xff08;资料包括C/C&＃43;&＃43;&＃xff0c;Linux&＃xff0c;golang技术&＃xff0c;Nginx&＃xff0c;ZeroMQ&＃xff0c;MySQL&＃xff0c;Redis&＃xff0c;fastdfs&＃xff0c;MongoDB&＃xff0c;ZK&＃xff0c;流媒体&＃xff0c;CDN&＃xff0c;P2P&＃xff0c;K8S&＃xff0c;Docker&＃xff0c;TCP/IP&＃xff0c;协程&＃xff0c;DPDK&＃xff0c;ffmpeg等&＃xff09;&＃xff0c;免费分享

由于读写分离&＃xff0c;双buffer机制下的数据读写不会出现竞争条件。在备份map 中数据更新完成时&＃xff0c;必然需要一种方式&＃xff0c;使得新数据能被使用到。这里需要做的就是把主map和备份map 的共享指针指向的内容互换&＃xff0c;即ptr 和bak_ptr 指向的内容互换。指针切换如下图所示&＃xff1a;

那么&＃xff0c;在指针互换时&＃xff0c;会出现什么问题呢&＃xff1f;

在指针的切换过程中&＃xff0c;会出现如下两个问题&＃xff1a;

• 由于对主map 的读是多线程的读&＃xff0c;会出现多线程同使用主map 共享指针ptr 的情形&＃xff0c;而互换指针时&＃xff0c;需要对主map 的指针进行写操作&＃xff0c;那么对同一指针 ptr 的读和写的竞争条件如何解决&＃xff1f;
• 在准备互换ptr 和 bak_ptr 指向的内容时&＃xff0c;如果某个读线程正在使用 ptr 访问主map&＃xff0c;直接互换就可能出现读线程再通过ptr获取数据时访问失效的问题&＃xff0c;严重的情况下会访问到无效内存导致程序崩溃。这一问题本文简称为”指针访问丢失“问题&＃xff0c;类似于常规指针中出现的野指针或悬垂指针的问题。

当指针切换时&＃xff0c;单线程对 bak_ptr 的写操作已经完成&＃xff0c;因而对其可以随便读写。但由于多个读线程可能还在使用ptr&＃xff0c;切换指针时对 ptr 的读写就要十分的小心。为了避免对 ptr 的读写出现竞争条件&＃xff0c;本文使用了自旋锁来对ptr 的读写进行同步。使用自旋锁的原因有两个&＃xff1a;

• 只在指针切换时使用锁&＃xff0c;而不是在读写两个map 时使用锁&＃xff0c;因而锁的使用频率会非常的低&＃xff0c;由此导致的上下文切换的代价是可接受的。
• 由于指针切换时 ptr 处于的情形是一写多读&＃xff0c;指针互换准备对 ptr 进行写操作时&＃xff0c;要获取锁的等待时间并不长&＃xff0c;并不会有长时间的锁等待出现&＃xff0c;因而可以使用代价更小的自旋锁&＃xff0c;而不是使用代价更高的读写锁。

上面已经介绍了指针访问丢失的情形&＃xff0c;即在两个指针切换时&＃xff0c;多个读线程可能正在使用ptr。为了避免出现读线程会读取到无效数据&＃xff0c;本文使用的方法是利用共享指针的引用计数来实现指针的延迟互换。

解决ptr 的竞争条件和指针访问丢失问题后&＃xff0c;就可以安全的使用双buffer 方案了。

最终的代码如下&＃xff0c;其中 mapptr 就是主map 指针&＃xff0c;bakptr 是备份map 的指针&＃xff1a;

class UpdateData
public:
UpdateData():flag_(0)

void PeriodTask();
void SetFlag(int i)
flag_ &＃61; i;

private:
shared_ptr

需要注意的是&＃xff0c;SwitchMapPtr 中调用 SetMainMapPtr(bakptr) 之后&＃xff0c;即使程序一直处在while 循环中&＃xff0c;再有新的线程通过 mapptr\\ 来访问主map 的数据时&＃xff0c;使用的已经是新的数据了。while 循环是为了解决指针访问丢失问题。当引用次数为1时&＃xff0c;即 unique 为真时&＃xff0c;表示已经没有读线程再使用旧的 map 了&＃xff0c;只剩下SwitchMapPtr 中old_map_ptr 这一个引用了&＃xff0c;这时可以安全的释放旧的map&＃xff0c;并把它清空当作备份map继续进行数据的更新操作。

从上面可以看出&＃xff0c;通过使用双buffer和共享指针&＃xff0c;避免了在一写多读模式中对数据的读写频繁加锁&＃xff0c;实现了”无锁“ 的设计。

即然双buffer可以很好的用于一写多读模式&＃xff0c;那么对于”多写一读“或”多写多读“模式&＃xff0c;是否也可以引入双buffer 模式呢&＃xff1f;

在含有多线程写同一变量的情形下下&＃xff0c;其实是不太适合使用双buffer 方案的。主要原因是&＃xff1a;

• 多写的情形下&＃xff0c;需要在 bak_map 的多个写操作之间通过锁来同步&＃xff0c;虽然避免了对读写互斥情形的加锁&＃xff0c;但是多线程写时通常对数据的实时性要求较高&＃xff0c;如果使用双buffer&＃xff0c;所有新数据必须要等到指针切换时才能被使用&＃xff0c;很可能达不到实时性要求。
• 多线程写时若用双buffer&＃xff0c;则在指针切换时也需要给bak_map 加锁&＃xff0c;并且也要用类似于上面的while 循环来保证没有线程在执行写入操作时才能进行指针切换&＃xff0c;而且此时也要等待多读的完成才能进行切换&＃xff0c;这时就会出现对 bak_map 的锁定时间过长&＃xff0c;在数据更新频繁的情况下是不合适的。

因而&＃xff0c;在多写的模式下&＃xff0c;还是优先用读写锁等操作系统提供的同步机制。

双buffer 方案在多线程环境下能较好的解决 “一写多读” 时的数据更新问题&＃xff0c;特别是适用于数据需要定期更新&＃xff0c;且一次更新数据量较大的情形。而这种情形在后台开发中十分常见。